Fix for the test failures is here: #466

Detected licenses are, in my opinion, much more valuable than declared licenses. If people really care about licensing, they need to care about what's really in the code, not what upstream declares.

What's the reason behind this change?

@msrb - I guess it was already discussed to use declared licenses. cc @krishnapaparaju Please let us know if there is any change.

@miteshvp yeah, I remember that we discussed how to go about ecosystems for which we won't have detected licenses, because artifacts are only available in binary form (.NET for example).

On the other hand, libraries in Golang usually don't have any manifest files so most of them won't have any declared license. We take licenses reported by GitHub and we have detected licenses.

@msrb looks like a cabal agenda. Adding it

[test]

@miteshvp Your image is available in the registry: docker pull registry.devshift.net/bayesian/cucos-worker:SNAPSHOT-PR-465

@msrb looks like a cabal agenda. Adding it

Good idea, thanks 😉

@miteshvp what's the plan here? you want to merge this now, or you want to wait for the cabal?

let's wait for the cabal. Thanks.

FWIW, ScanCode progressively also detects (and will provide a normalized license expression) for the "declared license". I call these "asserted" but that the same. https://github.com/nexB/scancode-toolkit/blob/275-streamline-package-manifests-models/src/packagedcode/models.py#L509

Also on the topic of Windows DLLs, there are two things there:

1. when in a nuget, there is a license URL in the nuspec or API data. These are progressively collected in ScanCode as detection rules to map these to a proper declared or asserted license.
2. DLLs have metadata such as a copyrights and sometimes licenses. If you scan these (which is somewhat heavy) these metadata will be detected soon when this branch is merged: https://github.com/nexB/scancode-toolkit/blob/275-streamline-package-manifests-models/src/packagedcode/win_pe.py

@msrb you also wrote:

Detected licenses are, in my opinion, much more valuable than declared licenses. If people really care about licensing, they need to care about what's really in the code, not what upstream declares.

I could not agree more, but both are worth IMHO. But in some areas such as NPMs that I think defaults to have an ISC license when none is set, there is a huge amount of discrepancies in these cases between the "declared" license as found in a package.json or regsitry API call and the actual license detected in the code.
My 2 cents is to always take a package.json ISC as not something to put in the bank.

Thanks @pombredanne for a detailed comment. It really helps and will consider NPM case accordingly.

Also related: fabric8-analytics/fabric8-analytics-license-check#9 (we don't use this tool anymore, but in this issue we were also discussing the same topic)

So, @msrb - we discussed this in cabal and we will go with declared_license and gradually will move to detected_license for some ecosystem and declared_license for some or in combination of both later.